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(54) Processing network address identifiers 

(57) The invention provides a method, data 
processing system and software for generating address 
identifiers for use in a communications network. The 
method comprises the step of processing a first address 
identifier constructed in accordance with a first commu- 
nications protocol; and the step of constructing a second 
address identifier, from said first identifier, in accord- 
ance with a second communications protocol. The first 
communications protocol may be protocol Simple Mail 
Transfer Protocol (SMTP) and the second communica- 
tions Session Initiation Protocol (SIP). The invention en- 
ables messages to be sent to a SIP URL derived from 
an SMTP email URL. In the event that the SIP URL is 
invalid, or unregistered the SIP message is diverted 
from a SIP defined destination URL address identifier to 
a corresponding SMTP defined destination URL ad- 
dress identifier for the same user or end system. In this 
way users may send SIP messages to SMTP address 
identifiers using the SMTP network protocol and infra- 
structure (416) and SMTP messages to SIP address 
identifiers usingthe SIP network protocol and infrastruc- 
ture (408, 410,412). 




Figure 4 



CO 
CO 
CM 

1^ 
CO 



CL 
LU 



Printed by Jouve, 75001 PARIS (FR) 



1 



EP 1 137 236 A1 



2 



Description 

[0001] This invention relates to processing network 
address identifiers for use in a communications network, 
and in particular to a method, data processing system 
and software application program for processing net- 
work address identifiers constructed in accordance with 
a communications control protocol. The invention is par- 
ticularly, but not exclusively, directed to text-based ap- 
plication-layer communication control protocols. 
[0002] The Session Initiation Protocol (SIP) is an ap- 
plication-layer control protocol for creating, modifying 
and terminating sessions having one or more partici- 
pants. These sessions include Internet multimedia con- 
ferences, Internet telephone calls and multimedia distri- 
bution. Members in a session can communicate via mul- 
ticast or via a mesh of unicast relations, or a combination 
of these. SIP supports session descriptions that allow 
participants to agree on a set of compatible media types. 
It also supports user mobility by proxying and redirecting 
requests to the user's current location. SIP is not tied to 
any particular conference control protocol. There is 
widespread interest in the protocol, especially for te- 
lephony-related applications. SIP was proposed by the 
Internet Engineering Task Force (IETF) group and is 
now a proposed standard published as RFC 2543. 
[0003] The entities used in SIP are user agents, proxy 
servers, redirect serves and location servers. A SI P user 
agent is an end-system that allows a user to participate 
in a session. A SIP user agent contains both a user 
agent client and a user agent server. A user agent client 
is used to initiate a session and a user agent server is 
used to respond to request from a user agent client. A 
user is addressed using an email-like address identifier 
"user@host", where "user" is a user name or phone 
number and "host" is a domain name or numerical In- 
ternet Protocol (IP) address. SIP defines a number of 
request types, in particular INVITE, ACK, BYE, OP- 
TIONS, CANCEL, and REGISTER. Responses to SIP 
messages indicate success or failure, distinguished by 
status codes, 1 xx (1 00 to 1 99) for progress updates, 2xx 
for success, 3xx for redirection, and higher numbers for 
failure. Each new SIP transaction has a uniquecall iden- 
tifier (call ID), which identifies the session. If the session 
needs to be modified, e.g. for adding another media, the 
same call identifier is used as in the initial request, in 
order to indicate that this is a modification of an existing 
session. 

[0004] The SIP user agent has two basic functions: 
listening for incoming SIP messages, and sending SIP 
messages upon user actions or incoming messages. 
The SIP user agent typically also starts appropriate ap- 
plications according to the session that has been estab- 
lished. The SIP proxy server relays SIP messages, so 
that it is possible to use a domain name to find a user, 
for example using the Domain Name System (DNS) 
rather than knowing the IP address or name of the host. 
A SIP proxy can thereby also be used to hide the loca- 



tion of the user. A redirect server returns the location of 
the host rather than relaying the SIP message. Both re- 
direct and proxy servers accept registrations from users, 
in which the current location of the user is given. The 
5 user's location can be stored at a dedicated location 
server. 

[0005] SIP is typically implemented by transmitting In- 
ternet Protocol (IP) packets. SIP is independent of the 
packet layer and only requires an unreliable datagram 
io service, as it provides its own reliability mechanism. 
While SIP typically is used over UDP or TCP, it could be 
used over frame relay, ATM AAL5 or X.25. 
[0006] SIP is a text based protocol and is based to a 
certain extent (in terms of syntax) on the HTTP protocol. 
is a typical message consists of a single request line, a 
number of header lines and a message body. 
[0007] The request line indicates the type of the mes- 
sages, the message destination and the SIP version it 
complies with. The following is a typical example: 

INVITE stp:Richard@bt.com SIP/2.0 
[0008] A header line contains the name of the header 
type, followed by a semicolon and the contents as these 
are defined for the specific header. Consequently, each 
header type is used for a specific purpose (either to in- 
dicate some parameters or to issue a request). The fol- 
lowing are typical examples: 

From: sip:Richard@bt.com 
To: sip:Steve@bt.com 
Subject: Official meeting 

[0009] The message body may be of any content, al- 
though it usually has contents formatted in accordance 
with the Session Description Protocol (SDP). 
[001 0] SIP URL address identifiers such as sip:Rich- 
ard@bt.com are required for the exchange of SIP mes- 
sages in a similar way that e-mail URL address identifi- 
ers are required for the exchange of electronic mail. 
[0011] By using an e-mail type address it is possible 
to deliver a SIP message to a SIP server that knows the 
location of the user or user agent server the message 
is intended for. The IP address of the SIP server having 
authority for the callee's address can be readily deter- 
mined by DNS. However, this approach requires users 
of both SIP and e-mail services to be allocated different 
and potentially confusing SIP and e-mail addresses. 
This exacerbates the problem of address memory, ad- 
dress book maintenance and in particular, address res- 
olution using database queries. 
[001 2] According to an aspect of the present invention 
there is provided a method of generating address iden- 
tifiers for use in a communications network; said method 
comprising the steps of:- 

processing a first address identifier constructed in 
accordance with a first communications protocol; 
and, 

constructing a second address identifier, from said 



25 



30 



35 



40 



45 



50 



2 



3 



EP1 137 236 A1 



4 



first identifier, in accordance with a second commu- 
nications protocol. 

[0013] In this way, it is possible to derive unique ad- 
dress identifiers for new communications services to be 
provided over a newly implemented communications 
protocol from respective address identifiers provided for 
services associated with a fully implemented communi- 
cations protocol. The above method provides for a new 
address space to be created for use with DNS or other 
address resolution systems for the provision of commu- 
nication services associated with a newly available com- 
munications protocol. The invention also provides for 
translation between address spaces. For instance, if a 
message is sent but not delivered to a user or location 
identified by an address identifier generated in accord- 
ance with the above method, the address identifier can 
be resolved back to its respective original address iden- 
tifier and the message sent to the location associated 
with that original address by means of a service availa- 
ble over the first communications protocol. In this re- 
spect, address resolution is readily achievable since the 
respective first and second address identifiers are di- 
rectly derivable from one another. This avoids the usual 
requirement of providing and maintaining of a costly ad- 
dress database for mapping respective first and second 
address identifiers. Another advantage of the above 
method is that the address space is readily scalable. For 
instance, by using the domain name hierarchy associ- 
ated with the first communications protocol a new do- 
main name hierarchy can be created and integrated, if 
appropriate, with DNS. A further advantage of the above 
method is that users can readily address messages etc, 
for transmission over one communications protocol us- 
ing an address identifier associated with another com- 
munication protocol. The ability to make use of the ad- 
dress space associated with a widely implemented com- 
munications protocol is very important when say new 
services are to be introduced using a new protocol. For 
example, a user may address a message to another us- 
er using a new address identifier derived from a known 
identifier regardless of whether the user is aware of the 
recipient's address identifier for the newly introduced 
protocol or whether the recipient has indeed been allo- 
cated a new address identifier or is capable of receiving 
the message over the new protocol. The user sending 
the message only requires knowledge of the recipient's 
address identifier associated with the widely implement- 
ed protocol. 

[0014] Preferably, said first identifier is processed in 
accordance with a pre-determined set of rules to provide 
said second identifier. 

[0015] Conveniently, said first identifier comprises at 
least one address component and said second identifier 
comprises at least one address component of said first 
identifier. In this way address components can be com- 
mon to both first and second address identifiers. 
[001 6] In preferred embodiments, said second identi- 



fier includes each address component of said first iden- 
tifier. This simplifies address translation and allows us- 
ers to intuitively derive one address identifier from the 
other identifier. This enhances the integration of servtc- 
5 es provided over a newly introduced communications 
protocol with services provided over an existing com- 
munications protocol. 

[0017] Preferably, said step of constructing said sec- 
ond identifier comprises the step of adding one or more 
10 address components to said first identifier. This enhanc- 
es the above mentioned advantages. 
[0018] Conveniently, said method comprises the 
steps of adding at least one prefix address component 
and at least one suffix address component to said first 
is identifier. This provides for the addition of at least two 
further distinguishing address components. 
[0019] In preferred embodiments, said prefix address 
component is representative of the second communica- 
tions protocol and said suffix component is representa- 
tive of a network domain associated with said second 
network communications protocol. This allows users to 
identify the communications protocol that is associated 
with the newly generated address identifier and the net- 
work domain authority for that address identifier. 
[0020] Preferably, said second communications pro- 
tocol is an application layer control protocol. This pro- 
vides for the implementation of user applications and 
new communications services over said communica- 
tions protocol. 

[0021] Conveniently, the control protocol conforms to 
Session Initiation Protocol. Thus SIP messages can be 
addressed to an existing address identifier, for example 
and e-mail address identifier constructed in accordance 
with Simple Mail Transfer Protocol (SMTP), and trans- 
lated to a corresponding SIP address identifier for trans- 
mission to a SIP user agent server regardless of wheth- 
er the SIP address identifier is known to the user. Thus, 
the present invention enables messages to be readily 
diverted from a SIP defined destination URL address 
identifier to a corresponding SMTP defined destination 
URL address identifier for the same user or end system. 
In this way users may send SIP messages to SMTP ad- 
dress identifiers using the SMTP network protocol and 
infrastructure and SMTP messages to SIP address 
identifiers using the SIP network protocol and infrastruc- 
ture. 

[0022] In preferred embodiments, a software program 
is arranged to implement the method according to the 
above-described aspect of the invention. 
[0023] According to another aspect of the invention 
there is provided a system for generating address iden- 
tifiers for use in a communications network; said system 
comprising:- 

a processor for processing a first address identifier 
constructed in accordance with a first communica- 
tions protocol; and, 

an address identifier constructor for constructing a 
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second address identifier, from said first identifier, 
in accordance with a second communications pro- 
tocol. 

[0024] The invention will now be described with refer- 
ence to the accompanying drawings in which:- 

Figure 1 a is a schematic representation of a typical 

SIP message signalling sequence in a network 

comprising a SIP re-direct server; 

Figure 1 b is a schematic representation of a typical 

SIP message signalling sequence in a network 

comprising a SIP proxy server; 

Figure 2 is a block diagram of a SIP user agent; 

Figure 3 is a block diagram of a SIP user agent 

graphical user interface; 

Figure 4 is a schematic representation of a commu- 
nications network comprising a plurality of SIP en- 
abled network domains; and, 
Figure 5 is a flow diagram of a method implemented 
in the communications network of Figure 4; 

[0025] With reference to the drawings, typical signal- 
ling sequences are shown in Figures 1 a and 1 b between 
two user agents 1 00 and 1 02 connected over a commu- 
nications network using a SIP redirect server 106 {Fig- 
ure 1 a), and a SIP proxy server 108 (Figure 1 b). In both 
arrangements a SIP location server 1 10 is connected to 
the respective SIP network server for address resolu- 
tion. 

[0026] In Figure 1 a, user agent 1 00 sends a SIP Invite 
message 112 to user agent 102. The Invite message is 
received at and processed by the re-direct server 1 06 
to determine the network location of user agent 1 02. The 
re-direct server sends a location query 114 to the loca- 
tion server 1 1 0. The location server determines the cur- 
rent network location of user agent 102 and sends this 
information to the re-direct server in a message 116 for 
transmission to the user agent 100 in a message 118. 
User agent 100 then sends an Invite message 120 to 
user agent 1 02, either directly or via other SIP re-direct 
or proxy servers, which then responds by sending an 
acceptance message 122 to the user agent 100. User 
agent 1 00 completes the session or call set up proce- 
dure by sending an acknowledgement 124. Once the 
session has been set up information can be exchanged 
between the respective user agents. 
[0027] In Figure 1 b, user agent 1 00 sends a SIP Invite 
message 126 to user agent 102 as before but instead 
of being processed by a re-direct server the message is 
processed by the network proxy server 108. The proxy 
server sends a location query 1 28 to the location server 
1 1 0. The location server determines the current network 
location of the user agent 1 02 and sends this information 
back to the proxy server in a message 130. The proxy 
server then relays the Invite message to the user agent 
1 02 by means of a message 1 32 which is processed by 
the user agent 102. A call acceptance message 134 is 



then sent back to the proxy server which relays a corre- 
sponding message 1 36 to the user agent 1 00. The user 
agent 100 then sends an acknowledgement message 
138 to the proxy server which similarly relays a corre- 

5 sponding message 1 40 to the user agent 1 02. 

[0028] With reference now to Figure 2, a typical SIP 
user agent 200 comprises a front end system in the form 
of a graphical user interface (GUI) 202, a SIP client pro- 
gram 204, a SIP server program 206, a media module 

10 208, a network interface 210 a SIP address cache 212, 
a SIP URL address generator 214 and a SIP message 
processor 216. 

[0029] A typical SIP GUI is shown in Figure 3. The 
GUI 202 comprises a plurality of buttons 302 to 3 1 0 each 
is of which represents a different SIP request method. But- 
ton 302 represents the SIP "INVITE" request for inviting 
a callee to a SIP session, button 304 represents the 
"OPTIONS" request for discovering the capabilities of 
the receiving terminal, button 306 represents the "BYE" 
request for terminating a call or a call request, button 
308 represents the "CANCEL" request for terminating 
incomplete call requests and button 31 0 represents the 
"REGISTER" request method for registering the current 
location of the user with a respective domain location 
database 1 1 0. The respective request methods are in- 
voked by a user clicking the respective button, by mouse 
controlled cursor click or otherwise. The GUI further 
comprises a text box 31 4 labelled 'To: SI P URL" for user 
input, by keyboard entry or address book entry selection 
for example, of theSIP address identifier of an intended 
caliee, that is to say the SIP destination message head- 
er field 'To"; a text box 31 6 labelled "To: e-mail URL" for 
user input of the e-mail address identifier of the intended 
callee; and, a text box 31 8 labelled "Title" for displaying 
title information to identify the session. A further text box 
320 is provided for the input of other SIP message text 
including for example other SIP header types and text 
comprising the SIP message body. Text may be input 
into any one of the text boxes 31 4, 31 6, 31 8, 320 using 
known text processing means, for example, keyboard 
entry, selection from pull down menus or cut and paste 
text processing applications. 

[0030] The SIP message constructor is configured to 
process data entered into any one of the boxes 314, 
316, 320, 320 and construct a SIP message including 
the relevant request type for transmission to an appro- 
priate SIP network server. For example, the message 
constructor copies the text entered in the text box 314 
to the SIP message header type "To:" in the SIP mes- 
sage being constructed. Other header types are deter- 
mined by the message constructor such as "Content- 
type:" and "Content length:" for example . 
[0031 ] The user agent client program is configured to 
initiate a SIP session or "call" and the user agent server 
program is configured to respond to a call. In this regard 
the user agent client program implements the SIP re- 
quest methods Invite, Options, Bye, Cancel and Regis- 
ter, and the user agent server implements the methods 
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Invite, Bye, Cancel and Ack methods. Messages are 
passed from the user agent client to the network inter- 
face 21 0 for transmission to the intended callee associ- 
ated with the destination SIP URL address. SIP mes- 
sages are received at the destination end by the network 
interface and are processing by the user agent server. 
The media module 208 provides the necessary API's for 
sending system calls to appropriate media applications 
for processing different media types once a SI P session 
has been established. 

[0032] When a user wishes to initiate a SIP session, 
the user interacts with the GUI 202 to construct a SIP 
Invite message including a destination SIP ore-mail ad- 
dress. Once all the necessary data has been input to 
the GUI, Including the SIP header types and message 
body, the message processor constructs an appropriate 
SIP message for transmission to the callee. In the event 
that the callee's SIP URL address is unknown to the us- 
er, the user inputs the callee's SMTP e-mail address in 
the text box 31 6. The e-mail address is then sent to the 
SIP URL generator 214. 

[0033] The SIP URL generator 214 comprises a soft- 
ware program for generating a SIP URL address iden- 
tifier from a respective SMTP e-mail address identifier 
for a respective user. 

[0034] The SIP URL generator is configured to proc- 
ess the e-mail address identifier, in accordance with a 
set of pre-determined rules, to generate a correspond- 
ing SIP URL address identifier for the callee. In one ar- 
rangement, the e-mail address is processed by the SIP 
URL generator which adds a prefix address component 
to the existing e-mail address components "user® host" 
etc. The prefix address component identifies the com- 
munications protocol that the new URL is to be used 
with. In this embodiment "sip" is added as a prefix. A 
suffix address component is also added to identify a SIP 
domain name authority the newly generated SIP URL 
address identifier is to be identified with. In one example 
the SIP URL generator is configured to process the 
SMTP e-mail address "alan.oneill@bt.com" to derive 
the SIP URL address identifier "sip:alan. oneill@bt.com. 
sipit.com", that is to say, to add the protocol prefix "sip" 
and the domain suffix "sipit.com" to the existing SMTP 
readable e-mail address "alan.oneil^bt.com". Thus, 
the SIP URL generator is configured to generate SIP 
URL address identifiers by processing a respective ad- 
dress identifier constructed in accordance with the In- 
ternet e-mail communications protocol SMTP. In anoth- 
er example the SIP URL generator is configured to proc- 
ess the same SMTP e-mail address identifier to derive 
the SIP URL address identifier "sip:alan. oneiil@bt.com. 
uk.sipit.com", that is to say a geographical identifier "uk" 
is additionally added to the SMTP e-mail address iden- 
tifier. The additional geographic identifier may assist 
scalability of the name space and hence network routing 
efficiency of the resulting SIP message, for example. 
[0035] Referring now to Figure 4, a plurality of network 
domains 400, 402 and 404 are each connected to the 



Internet 406 by means of a respective SIP network serv- 
er 408, 410 and 41 2. In the network of Figure 4 the SIP 
network servers are configured for use both as SIP 
proxy and SIP re-direct servers. The SIP network serv- 
5 ers provide access to and from the respective domains. 
Each network domain comprises a plurality of SIP user 
agents 200(a-g). SIP user agents 200a, 200b and 200c 
are connected to the network server 408 in the domain 
400, SIP user agents 200d, and 200e are connected to 
10 the network server 41 0 in the domain 402, and SI P user 
agents 200f and 200g are connected to the network 
server 412 in the domain 404. Each SIP network server 
is connected to a respective location server 110 for SIP 
address resolution and an associated SIP to SMTP e- 
'5 mail gateway 414. Each SMTP e-mail gateway is con- 
nected to a respective SMTP Mail Transfer Agent (MTA) 
416 for relaying SMTP e-mail messages to respective 
destination SMTP MTA's over transport layer TCP con- 
nections. 

[0036] Each SIP to SMTP e-mail gateway 414 com- 
prises an SMTP e-mail address generator 418 and a 
message processor 420 which comprises an SMTP us- 
er agent. The e-mail address generator comprises soft- 
ware for generating an SMTP address identifier from a 
SIP URL address identifier. In this regard the e-mail ad- 
dress generator is configured in a similar but reverse 
manner to the address generator 214. The e-mail ad- 
dress generator is configured to process the SIP URL 
destination address identifier of an out going SIP mes- 
sage to derive a corresponding SMTP e-mail address 
identifier. The e-mail address generator processes the 
SIP URL address in accordance with the same pre-de- 
termined set of rules as the SIP address generator 214, 
but processes these rules in reverse order with respect 
to the address generator 214. For instance, in one em- 
bodiment a SIP message arriving at the SIP to SMTP e- 
mail gateway 414 is parsed to determine the destination 
SIP URL. The SIP URL is then passed to the SIP to e- 
mail address generator 418. The remaining part of the 
SIP message is re-formatted by the message processor 
420 into SMTP format suitable for transmission as an 
SMTP e-mail message. 

[0037] In one embodiment the address generator 41 8 
is programmed in accordance with the above set of 
rules, that is to say to remove the protocol identifier pre- 
fix "sip" from the SIP URL address and to remove the 
sip domain suffix component "sipit.com". The address 
generator sends the re-formatted SMTP address iden- 
tifier to the message processor where the newly derived 
SMTP address is added to the re-formatted message 
as the destination SMTP address for that message. The 
message processor adds the newly generated SMTP 
address to the SMTP "To:" header field of a respective 
SMTP message. For example, the address generator 
418 is programmed to derive the SMTP e-mail address 
identifier alan.oneill@bt.com from SIP URL "sip:alan. 
oneill@bt.com.sipit.com H . 

[0038] The message processor 420 constructs an ap- 
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propriate SMTP message for transmission to the newly 
generated SMTP address according to the content of 
the respective SIP control message. For example, the 
SIP message payload, for example the SDP message 
component of the SIP message , is added as text to the 5 
respective SMTP message body for transmission to the 
respective destination SMTP address. In the example 
described with reference to Figure 3, the SDP text 
shown in box 320 is processed and added as text to the 
SMPT message payload by the message processor 10 
420. 

[0039] With reference now to the flow diagram of Fig- 
ure 5, a user initiates a SIP session in step 500 by in- 
teraction with the GUI 202 of a SIP user agent 200. A 
data entry for each of the required data types is input by is 
the user including a destination SIP address in box 314 
or, in the absence of a known SIP URL for the intended 
recipient, an SMTP e-mail address that is known to be 
allocated to the recipient in box 31 6. Data relating to the 
SIP message is processed into SIP format by the SIP 20 
message processor 21 6 and is then submitted to the us- 
er agent client 204 by the user selecting the Invite button 
302 by mouse click or other data input command. The 
user agent client determines in step 502 whether a SIP 
URL address has been provided or an SMTP e-mail ad- 25 
dress. If a SIP URL has been provided processing pro- 
ceeds to step 508. However, if an SMTP e-mail address 
identifier has been provided the user agent client sends 
the e-mail address to the address generator 214 for 
processing to a respective SIP URL address identifier 30 
in step 504. A respective SIP URL is generated in ac- 
cordance with the above described method. In step 506 
the newly derived SIP URL address is added to the SiP 
destination header type "To:" following the INVITE re- 
quest type of the SIP message. 35 
[0040] The SIP message is transmitted to the appro- 
priate local SIP network server 408,410 or 412 in step 
508 to be relayed or re-directed to a network server as- 
sociated with the destination SIP U RL address. The net- 
work server that receives the SIP message queries its 40 
associated location database 110 in step 510, using 
DNS or other address resolution means, to determine 
the network server the SIP message should be trans- 
mitted to. In step 512 a network server having authority 
for the domain for the destination SIP URL determines 45 
whether the destination SIP URL address is a valid net- 
work address, that is to say, whether the SIP URL ad- 
dress has been allocated by the domain authority to a 
SIP user. The SIP URL destination address is a valid 
network address if it can be resolved by a location da- so 
tabase using DNS or other resolution means to a re- 
spective numerical IP address, for example. In this re- 
spect address resolution may involve querying other lo- 
cation databases associated with other network SIP 
servers or SIP domains in a similar way that DNS re- 55 
solves numerical IP addresses. In step 514, if the des- 
tination SIP URL address is valid, that is to say it has 
been allocated to a respective user and can be resolved, 



the location server returns the IP address of the next 
SIP server that is configured to relay or re-direct the 
message or if appropriate the I P address of the end sys- 
tem currently associated with the destination SIP URL. 
The SIP message is sent to the next SIP network server 
or destination end system in step 51 6. If the SIP URL is 
invalid, that is to say it has not been allocated by the 
appropriate domain authority for use in the network, an 
appropriate SIP network server transmits the SIP mes- 
sage to an associated SIP to SMTP e-mail gateway in 
step 516. The destination SIP URL may be invalid for 
instance because it was automatically generated from 
a known e-mail address identifier in step 504 and no cor- 
responding SIP address exists. Under these circum- 
stances the message processor 420 re-formats the SIP 
message to an SMTP message for communication over 
the Internet 406 in accordance with SMTP in step 518. 
In step 520 the destination SIP URL address is proc- 
essed by the address generator 418 in step 520 to de- 
rive the SMTP e-mail address encapsulated within the 
SIP URL address. Additional information and data is 
added to the re-formatted SMTP e-mail message in step 
522 including, for example the text:- 

"You were called by SIP user < sender's SIP URL 
and associated data> at <time, date> with message 
<SIP message body content (SDP) > but you were 
not found in the SIP registration system. You can 
register at <http hyperlink> where you can down- 
load a SIP client." 
or, 

"You were called by SIP user <sender , s SIP URL 
and associated data> at <time, date> with message 
<SIP message body content (SDP)> but you were 
not found in the SIP registration system. You can 
register using the attached http form <http registra- 
tion form with mailto: URI address>. A SIP client 
<SIP client executable code> is attached." 

[0041] The SMTP message is sent to an associated 
mail transfer agent 41 6 in step 524 for transmission to 
the e-mail address derived in step 520 using the SMTP 
network protocol. In step 526 the sender is informed by 
the SIP server that the destination SIP URL was not val- 
id and that the message was instead re-formatted ac- 
cording to SMTP and sent to the SMTP e-mail address 
derived in step 520. 

[0042] It will be seen that the other embodiments of 
the present invention could be readily implemented by 
the skilled person, for instance instead of the SIP mes- 
sage being diverted to a SIP to e-mail gateway in the 
event that the destination SIP URL address is invalid, a 
SIP message could be readily diverted to a SIP to e-mail 
gateway if the user or the end system associated with 
the user was unavailable or unwilling to receive SIP 
messages at the time of message transmission. In one 
embodiment, the respective SIP server selects an ap- 
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propriate message from an associated message library 
(not shown) for inclusion with the original SIP message 
in step 522. The message library includes a respective 
delivery failure message for each SIP message delivery 
failure mode, including for example, destination SIP us- 
er agent unavailable, user unavailable, network connec- 
tion failure, user unwilling to join SIP session or user 
unwilling to join designated sessions, user will be avail- 
able at <time, date>, etc. 

[0043] It will also be seen that in other embodiments 
the SIP to e-mail gateway 414 could be readily imple- 
mented in other network devices such as a respective 
network SIP server or a SIP user agent. 



8. A method according to any preceding claim wherein 
said second communications protocol is an appli- 
cation layer control protocol. 

5 9. A method according to claim 8 wherein the control 
protocol conforms to Session Initiation Protocol. 

1 0. A software program arranged to implement a meth- 
od according to any preceding claim. 

w 

11. A system for generating address identifiers for use 
in a communications network; said system compris- 
ing:- 



Claims 

1. A method of generating address identifiers for use 
in a communications network; said method com- 
prising the steps of:- 

processing a first address identifier constructed 
in accordance with a first communications pro- 
tocol; and, 

constructing a second address identifier, from 
said first identifier, in accordance with a second 
communications protocol. 

2. A method according to claim 1 wherein said first 
identifier is processed in accordance with a pre-de- 
termined set of rules to provide said second identi- 
fier. 



a processor for processing a first address iden- 
tifier constructed in accordance with a first com- 
munications protocol; and, 
an address identifier constructor for construct- 
ing a second address identifier, from said first 
identifier, in accordance with a second commu- 
nications protocol. 



A method according to claim 2 wherein said first 
identifier comprises at least one address compo- 35 
nent and said second identifier comprises at least 
one address component of said first identifier. 

A method according to claim 3 wherein said second 
identifier includes each address component of said 40 
first identifier. 



5. A method according to any preceding claim wherein 
said step of constructing said second identifier com- 
prises the step of adding one or more address com- 45 
ponents to said first identifier. 



6. A method according to claim 5 wherein said method 
comprises the steps of adding at least one prefix 
address component and at least one suffix address so 
component to said first identifier. 



7. A method according to claim 6 wherein said prefix 
address component is representative of the second 
communications protocol and said suffix compo- 55 
nent is representative of a network domain associ- 
ated with said second network communications pro- 
tocol. 
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